\documentclass{article}
\usepackage{graphicx}
\begin{document}
%# Translator architecture (to be written by the system architect)
%    * Show the architectural block diagram of translator.
%    * Describe the interfaces between the modules.
%    * State which modules were written by which team members.
\section{Translator architecture}

\begin{figure}[htp]\begin{center}
\includegraphics[scale=0.5]{block.eps}
\caption[Block diagram]{A block diagram of the Pigasus compiler. The input source is lexed and parsed, and the each resulting .cc file is compiled.}
\label{fig:block}
\end{center}\end{figure}

Figure~\ref{fig:block} shows the block diagram for Pigasus. As it indicates, the source pig file is first sent into the lexer and parser. This not only translates the Pigasus code, but also breaks it up so that each job is in a separate file. Thus, PigMain will be compiled into its own program, and each job will be compiled separately into its own executible. When we compile the programs, we only include the necessary files.

\begin{figure}[htp]\begin{center}
\includegraphics[scale=0.5]{arch.eps}
\caption[Backend architecture]{Backend archtecture overview. This illustrates how ``pushing'' a job actually works.}
\label{fig:arch}
\end{center}\end{figure}

Pigasus is actually a fairly straightforward language in terms of syntax, but it has a heavy backend. An overview is shown in figure~\ref{fig:arch}. At some point, \verb|PigMain()| will push a job. When it does this, we create a separate thread called \verb|JobThread|. This thread will then parse the inputs list it is given and determine how many instances it needs to create; so, for example, if the inputs list is of length 5, we need to send out 5 instances. Instead of sending these in a loop, the \verb|JobThread| actually spawns one thread, called \verb|SendThread|, to do the work for it. Each \verb|SendThread| will create the remote environment, send the files, and start the job running in the background. After all the \verb|SendThread|s have been created, the \verb|JobThread| will iteratively poll each machine to see if it is done. We actually just make the script on the remote end generate a file called `\verb|done|' when it is finished, so we check if this file exists. If the instance has finished running, then the \verb|JobThread| launches a new thread, called \verb|GetThread|, which retrieves the files and returns the information to the \verb|JobThread|. The \verb|JobThread| will continue this until every single instance has finished and the data has been returned.

%# Development environment (to be written by the system integrator)
%    * Software development environment used
%    * Implementation languages and tools used
%    * Libraries used
\section{Development environment}

We developed Pigasus on all three major platforms: Linux (Ubuntu 9.04), Mac (OS X 10.5), and Windows (XP). However, Windows was only used for parsing--we do not support the standard Windows environment when actually running Pigasus code.

For lexing and parsing, we used flex and bison. Since this job was relatively straightforward, we only needed those two languages. On the backend, almost all of the work was done in C++, but thereare key components which are done in scripting languages. Since bash scripting is very good for interacting with the shell, anytime we need to execute a series of steps, we use a script. One particular case cropped up, however, where even bash wasn't enough: if the user gives us a password, there is no way to input this password to ssh from the command line. Our solution was to use a scripting language called \emph{expect}, which can interact with a program as if you are actually typing. For instance, we expect the phrase `password: ', and when we see this, we enter the password (the actual input will be something like `user@host's password').

\end{document}
